When a user attempts to interact with a services transaction system as is known to the inventor, it may happen that instead of the anticipated interaction resulting in some desired transaction, the user, after entering the data required to request a service transaction, receives an error message and is unable to complete the transaction. In current art, the only offered options for dealing with such error conditions are typically Retry and Abort (Cancel), and nothing else. The user experience is even more adverse in case the services that are procured asynchronously (where the user gets notified of the status of the transaction at a later point of time). In such cases, the current art, the only offered option is to let the user know the transaction has failed and get them to create a new request. If the error condition stems, for example, from a problem in a communication line, retrying continually does not produce any results other than continual errors, because the line is not going to be fixed by the user retrying. Thus the user must cancel the interaction and consequently loses all the data he has entered, resulting in wasted time and effort and considerable frustration.
What is clearly needed is a system and method for that offers more effective options for treatment of error conditions than the typical selection of Retry or Cancel options.